Description of Related Art
FIG. 1 is a diagram of a typical software development lifecycle, not necessarily limited to speech recognition systems. At block 10, a software design team defines the requirements applicable to a given computer software system. The term xe2x80x9cteamxe2x80x9d here refers to either an individual designer or to a group of designers working in concert. These requirements drive the design of the software system, as illustrated in block 12. After designing the system, the design team develops and implements a prototype system to fulfill those requirements, as shown in block 14. If the development stage reveals any design errors, the team returns to block 12 to correct those design errors. Typically, the design and development stages illustrated in blocks 12 and 14 entail significant investments of time and money.
At block 16, the prototype system is tested to ensure that it meets the requirements defined in block 10. In some circumstances, the testing shown in block 16 reveals design errors in the prototype system, and the design team must refine the system as shown in block 18 to identify fixes for those design errors. To identify these fixes, the design team may have to address either the design or the implementation of the system, shown in blocks 12 and 14, respectively. Once correct fixes are identified, the team returns either to block 12 or to block 14 to implement these fixes, depending on whether the system design (block 12) or the system implementation (block 14) must be addressed. The process is repeated until testing reveals that the system meets all applicable requirements. At this point, the system is considered completed, as shown in block 20.
As a general rule, whether developing speech recognition systems or other types of software, the later in the project development lifecycle that a design error is found, the more expensive it is to fix that design error. This general rule holds not only because fixing one design error may have a xe2x80x9cripple effectxe2x80x9d of creating additional design errors, but also because the system must be regression tested after the fix to ensure that fixing the first design error did not create other design errors. For example, if it costs a certain amount of money, X dollars, to fix a design error located during the design stage (block 12), it generally costs three times that amount of money, 3X dollars, to fix that same design error located in the development stage (block 14). Furthermore, if that same design error is initially located in the test stage (block 16), it costs about nine times that amount of money, 9X dollars, to fix that design error. Clearly, from a project management standpoint, it is advantageous to locate design errors as early in the project development lifecycle as possible. The cost of finding and fixing a design error grows exponentially in relation to the phase of a project in which the design error is located.
One drawback to the paradigm shown in FIG. 1 is that it does not typically locate system design errors early in the project lifecycle, that is before substantial resources, including time and money, have already been expended on the project. Note that the testing activities shown in block 16 typically do not occur chronologically until after the design and development stages, shown in block 12 and 14 respectively, have been completed to provide a functioning prototype. In more traditional software engineering methodologies, the design underlying the software system cannot be rigorously tested until the functioning prototype has been implemented. To implement such a prototype entails a significant investment of time and money. Accordingly, by the time the prototype system is ready for testing (block 16), significant time and money have already been invested in designing and developing the prototype system. Typically, the bulk of system design errors are located during the test stage (block 16), and as discussed above, design errors located during this stage are the most expensive to fix, because the design and development stages are already thought to be substantially complete.
In light of the above disadvantages of the software development lifecycle shown in FIG. 1, it would be advantageous to provide the capability to test the design before implementing a functioning prototype and before the design and development stages are substantially completed or have even begun. In this manner the testing step is moved earlier in the development methodology, where design errors are cheaper to fix. Accordingly, a need exists in the art for a software design methodology that promotes the location of system design errors relatively early in the project lifecycle, when such design errors are relatively inexpensive to fix. In addition to reducing the cost of locating and fixing errors, such a methodology would also reduce overall project cost in terms of both time and money. However, such a methodology would further provide the ability to evaluate designs using correct and appropriate physical senses, would improve the odds of overall project success, and would improve the chances of ultimate customer acceptance and understanding.
The present invention is directed to a method of developing a computer-based dialogue interface for an automated or computerized system. The dialogue interface is disposed between the automated system and an end user, with the dialogue interface receiving input from the end user and providing output to the end user in response to the input. In an illustrative embodiment, the method comprises the following steps. A system designer(s) defines a plurality of requirements applicable to the dialogue interface. The dialogue interface is then designed to meet these requirements. The automated system is simulated with at least a first person, and the end user is simulated with at least a second person. The dialogue interface is evaluated by facilitating an interaction between the first and the second persons through the dialogue interface. Based on the interaction between the first and the second persons, the dialogue interface is evaluated. Based on the evaluation of the dialogue interface, the dialogue interface is refined.
After performing the above steps, the automated system is then developed based upon the dialogue interface.